First of 6 PRs implementing Phase 3 (multi-model external audit) +
the open frictions F2/F5/F7. Framework-only — no CLI code yet.

Artifacts (all under dist/.devtrail/, auto-distributed via the existing
recursive manifest pattern):

- audit-prompts/auditor-primary.md
- audit-prompts/auditor-secondary.md
- audit-prompts/calibrator-reconciler.md
- schemas/audit-output.schema.v0.json

Architectural decision A1 (per the Phase 3 plan): Phase 3 v0 is
ORCHESTRATION-ONLY, not an HTTP-API client. The CLI prepares and
persists prompts, awaits the operator's responses, validates outputs
against the schema, integrates findings into the Charter telemetry —
but does NOT invoke any LLM API directly. Adopters paste the resolved
prompts into their auditor of choice (Copilot, Gemini, Claude, etc.),
save responses to the canonical paths, and the CLI consolidates.

Rationale for orchestration-only:
- Implementing 3 HTTP clients (OpenAI / Google / Anthropic) is 1-2
  weeks of work + perpetual maintenance when APIs change. For an
  EXPERIMENTAL v0 schema, that investment is premature.
- Sentinel's empirical pattern (the 6-cycle dual-audit experiment that
  motivated Phase 3) ALREADY uses this human-in-the-loop shape via
  /plan-audit skills. The CLI's value-add is the canon (prompt shape +
  output schema + telemetry integration), not the API call.
- Closes RFC #82 (audit visibility) by design — the prompt-resolution
  and the auditor's response are both files on disk, version-controlled,
  inspectable, and reproducible by hand if the API call fails.
- Aligns with principle #10 (honesty about what the tool does NOT do):
  "no LLM gateway, no model evaluation".

Schema design:
- audit-output.schema.v0.json uses oneOf to distinguish auditor outputs
  (primary/secondary, fresh findings) from calibrator outputs
  (reconciliation across the two). The `audit_role` field is the
  discriminator — three fixed roles, not arbitrary N.
- findings_by_category enum (hallucination | implementation_gap |
  real_debt | false_positive) is the same vocabulary used by the
  external_audit array in charter-telemetry.schema.v0.json. The audit
  cycle output integrates directly into Charter telemetry at close.
- Every output declares prompt_used: <relative path>, satisfying RFC
  #82's requirement that the prompt path be discoverable from the output.

Prompt design:
- Primary and secondary prompts are STRUCTURALLY IDENTICAL. The
  heterogeneity signal lives in the auditor MODEL (different family
  per §5.2), not in different prompts. A/B-testing prompt phrasings
  is forward-looking; v0 keeps them symmetric for clean comparability.
- Calibrator prompt assumes both auditor outputs as context and asks
  for status assignment (agreed | disputed | unique_primary |
  unique_secondary | rejected) per finding. Status counts cross-check
  against body section count — the schema enforces consistency.
- All three prompts include explicit categorization rules + discipline
  rules ("don't fabricate findings", "no external sources beyond the
  prompt"). The rules are duplicated across the three so the auditor
  doesn't need to consult external documentation.

What's NOT in this PR:
- No CLI code yet — the `devtrail charter audit` command lands in PR 2.
- No heterogeneity validation (`--implementer-family` enforcement) — v1.
- No invocation of LLM APIs — orchestration-only by design.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>